#

| Chapter 12 Job Control |

## 12.5 System Overloaded? Try Stopping Some Jobs

If your computer is barely crawling, you can kill (38.10) some processes... but you'll have to start them again later. On a Berkeley system, you can renice (39.11) the processes... but you won't be able to raise the priority again later, after the system speeds up, unless you're the superuser (1.24).

If you don't need your results right away (and you won't get them, anyway, if the system is crawling!), try stopping some jobs. The best candidates are "CPU-eaters" like formatters (43.12), compilers (52.8), and any job that runs up a lot of time quickly in the ps (38.5) or time (39.2) reports. Start them again, later, and the jobs will take up where they left off.

If the job is in the foreground, just press CTRL-z (12.1) to stop it. If the job is running in the background and you're running csh or tcsh, use the shell's stop command with a job identifier - for example, `stop %3` or `stop %cc`.

On other shells - even shells without job control (!) - you can use kill (38.10) with the -STOP signal and either the job number or process ID number. csh and tcsh have a stop command that does this for you. On other shells, if you'd like, you can add an alias named stop to the shell setup file (2.2). Later, put the job back into the background with bg, or into the foreground with fg. For example:

>     bash$ alias stop='kill -STOP'
>     bash$ jobs
>     [1]+  Running                 g++ hugeprog.cc &
>     bash$ stop %1
>     [1]+  Stopped (signal)        g++ hugeprog.cc
>         ...later...
>     bash$ bg %1
>     [1]+ g++ hugeprog.cc &

- JP

12.4 Job Control and autowrite: Real Time Savers! |  | 12.6 Notification When Jobs Change State